BBS in a Box 15

home *** CD-ROM | disk | FTP | other *** search

/ BBS in a Box 15 / BBS in a box XV-1.iso / Files / Internet / Misc / Uupc 3.1.sit / Documentation / Protocol notes / Protocol notes

Wrap

Text File | 1994-09-05 | 11.3 KB | 231 lines | [TEXT/ALFA]

Of protocols and paper bags, of packetings and pings. UUCP is a general-purpose, computer-to-computer file copying system, on top of which quite a number of different sorts of applications can be built. You can think of UUCP as a three-layer cake, with each layer handling a different aspect of the file transfer: - What files should be transferred? - How should they be transferred over a communications link? - What should be done with them when they arrive? It's possible to have two or more ways of implementing each of these layers, and to "mix and match" various combinations of these implementations to suit a particular need. The first layer... deciding which files should be transferred... is common to all implementations of UUCP. There is an agreed-upon process for saying things like: "I want to send you file 'foo', on behalf of a user 'joe' on this machine. OK?" "Yes, go ahead." "Here it is........" "OK, I got it." "Fine. User 'sam' on this machine wants you to send me a copy of file 'bar', OK?" "OK, here it is....." "Got it, thanks. I'm done." "I don't have anything to ask you to do at this point." "Fine. Goodbye." "Goodbye." The last layer... deciding what should be done with a file once it has been transmitted... is also fairly well standardized. Crudely speaking, the UUCP system transmits three kinds of files: - Those which describe a command to be executed by the other system... for example, "rmail bob" means "receive mail from somebody here, and send it to bob, please". - Those which describe data which is to be fed into a program being run on the other system... for example, a file would be sent which contained the message which was to be delivered to "bob". - Those which contain data being transferred for some other purpose... for example, source-file archives which are being transferred from a file-server system to a client. Most UUCP transfers involve the first two sorts of files... electronic mail messages, network-news articles, and the command-files which cause these messages and articles to be fed to the proper program for delivery or other processing. As you might guess, there are some real security issues here. You (as a system administrator) don't want to permit other people to execute arbitrary commands on your system, or to transfer files to or from your system's disks without your permission. Most implementations of UUCP place severe restrictions on which programs can be run via the file-transfer mechanism, and the directories into which files can be written (or read from). The lowest layer in the "cake"... that of actually transmitting the data over a communications line... is also fairly standardized. It has to be... if two UUCP systems don't speak a common communications protocol, they can't exchange any data... in fact, they cannot even tell each other which files they want to send! There are a number of different communication protocols available within the UUCP universe. The 'g' protocol is by far the commonest, and it's the one you'll most often encounter. uupc 3.0 also supports the 'f' protocol, and you may wish to use it under certain conditions. Other implementations of UUCP support the 't', 'e', and 'x' protocols, which uupc 3.0 does not understand and cannot use. The 'g' protocol ---------------- The 'g' protocol is an answer to the following question: "How can we transmit data, consisting of arbitrary 8-bit characters, over a telecommunications link which is capable of sending 8-bit data, but which is subject to noise and cannot be relied upon to deliver all of the characters correctly?" The 'g' protocol is most commonly used over normal dial-up modems. It can also be used with dedicated (leased-line) modems, or over direct machine-to-machine connections. 'g' is a "packet-oriented" protocol. The data being transmitted is broken up into packets, or chunks, of an agreed-upon size. The sender transmits one or more packets, and then waits for the receiver to acknowledge that the packets have been received correctly. Packets are numbered (so the receiver can tell if they have arrived in the proper order, or if a packet has been lost in transit) and contain a checksum and a CRC code (so the receiver can determine if any of the contents have been corrupted by noise on the phone line). The receiver sends back a series of short packets, to ACKnowledge the successful reception of a packet, or to Negatively AcKnowedge a packet which has been lost or damaged. If the sender receives a NAK, it "backs up" and retransmits packets starting with the first one which was lost or damaged. Most implementations of the 'g' protocol use a "sliding window". The sender transmits a burst of packets... typically 3 of them... and then waits for the receiver to ACK packet #1. Once packet #1 has been ACKed, the sender transmits packet #4 and waits for an ACK from packet #2, then sends #5 and waits for an ACK from #3, and so forth. The sender will almost always have a "window" of one or more packets which have been sent, and not yet acknowledged. The use of a multi-packet window improves the 'g' protocol's performance. If the window is only 1 packet wide, the sender must stop and wait for an ACK after each packet... and, because it will take the receiver some amount of time to check the packet's correctness and send back an ACK, the transmission will "stall" and the line will sit idle between packets.. If the window is two or more packets wide, then the sender can be transmitting a packet while the receiver is checking the previous one and sending back an ACK... and, with a bit of luck and a fair wind, the sender will always receive the ACKs in time to allow it to send another packet as soon as it's ready. By default, almost all UUCP implementations use the 'g' protocol with a 3-packet window, unless instructed otherwise. It gives good performance, and permits rapid recovery if a packet is damaged in transit. Under some conditions, it may be useful to increase the size of the 'g' protocol's window. This will increase the amount of unacknowledged data which can be "in transit" at any particular moment, and can reduce the impact of a "sluggish" receiving system (one which doesn't always acknowledge packets instantly) or of a telephone connection which delays transmissions significantly (for example, an overseas call via a geostationary satellite). You should not assume that a larger 'g' window will always increase performance, though. If your phone line is noisy, and packets are damaged in transmission at all frequently, then a larger window won't help much, and can actually hurt... most errors require the retransmission of an entire window's worth of data, and a larger window thus requires more retransmission. Also... there are cases in which some UUCP implementations say that they can handle a larger window, but in fact cannot do so gracefully. These implementations can "drop packets on the floor" if the packets arrive in large numbers at high speeds... this usually leads to protocol timeouts, retransmissions, and long delays. You can also increase the size of the packets used by the 'g' protocol. In theory, the 'g' protocol can use packets of sizes from 32 to 4096 bytes (the packet size is always a power of two). In practice, most uucp implementations use a hard-coded packet size of 64 bytes. Some can send packets of a few other sizes, if you ask them to; very few can accept packets of any size other than 64 without becoming acutely ill. Increasing the packet size can increase performance, because more data is transmitted per packet (each packet having a fixed amount of overhead) and because the total size of bytes in the window is increased. It can hurt performance over noisy phone lines, because more data must be retransmitted after an error. Furthermore, many uucp implementations behave very impolitely if one even attempts to negotiate a packet size of other than 64 bytes... some implementations send invalid packets, and some dump core or disconnect abruptly. Due to its sliding-window characteristic, the 'g' protocol is normally self-pacing - it will not send data faster than its peer can accept it. For this reason, it is usually unnecessary to use Mac-to-modem flow control with the 'g' protocol. You can, if you wish, enable hardware flow control with the 'g' protocl (see the "Modems and cables" document for instructions). You must NOT attempt to use software (XON/XOFF) flow control with the 'g' protocol - it won't work and will very probably cause your protocol to malfunction. The 'f' protocol ---------------- The 'f' protocol is an answer to the following question: "How can we transmit data, consisting of arbitrary 8-bit characters, over a telecommunications link which cannot send characters with their 8th bit turned on, or send certain control characters... but can be relied upon to deliver data reliably in almost all cases, and can be trusted to perform flow control at all stages of the link? The 'f' protocol was originally developed to send data over X.25 packet-switched networks (PSNs), via direct connections between a computer and a packet assembler/disassembler (PAD). It has also shown itself to be useful when sending data over a dial-up phone connection between computers whose modems support either MNP (the Microcom Network Protocol) or V.42. The 'f' protocol is a "streaming" protocol. Data is transmitted as a sequence of bytes, without packet headers or trailers. Data is sent continuously, except when the data link (modem or PAD) uses a flow-control mechanism to report that the link is becoming backlogged... at which point the transmission ceases until the link is once again free. The only characters transmitted over the link are printable 7-bit ASCII characters... any other (high-bit or control) characters in the original data are converted into two-character "escape sequences" by the sender, and are converted back into their correct form by the receiver. The receiver does not send back periodic ACK/NAK indications, as is done in the 'g' protocol. Instead, it calculates a checksum of the file, as the file is received. At the end of the file, the sender transmits the checksum that it has calculated, and the receiver checks this value against its own version. If the checksums match, the receiver says (in effect) "Got it!" If the checksums do not match, the receiver sends a "Beg pardon, how's that again?" and the sender retransmits the _entire_ file. As you can infer, the 'f' protocol is extremely sensitive to data errors... a single one-byte error anywhere in the file will cause the entire file to be retransmitted. For this reason, the 'f' protocol should _not_ be used over dial-up modem lines, unless the modems support MNP or V.42 error control and have been configured to use it. Similarly, the 'f' protocol should _not_ be used if you are running LocalTalk via your printer port... when LocalTalk packets arrive, the LocalTalk driver turns off interrupts for a few milliseconds, and this can cause your modem port to overrun its FIFO and lose a character or two. The 'f' protocol usually requires flow control to avoid overrunning buffers in your modem or network. Software (XON/XOFF) flow control is most commonly used at the Macintosh end; hardware handshaking can be used as well, if you have a suitable cable and modem (see the "Modems and cables" document for details).